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REMARKS/ARGUMENTS 

Reconsideration of this application is respectfully requested in view of the 
foregoing amendments and discussion presented herein. 

1. Interview with Examiner on July 28. 2008 . 

Applicant appreciated the opportunity to discuss the question of the TCP header 
field with the Examiner (and the other two Examiners) during the interview. The 
discussion answered the question of what the Examiner was 'asserting' to be explicit 
back-to-back indications in the TCP header, as nothing of this nature was found defined 
in the TCP header. In discussing this it was found that packet sequence numbering and 
packet fragmentation controls were being considered as indications of back-to-back 
sending. According to that discussion, Applicant has included a discussion of these 
aspects, and has amended the claims toward removing any confusion between the 
back-to-back nature of packets as recited in the pending claims and the nature of 
packet sequence numbering and fragment control techniques. 

2. Rejection of Claim 13 under 35 U.S.C. §112. second paragraph . 
Examiner indicated that the rejection of Claim 13 was not addressed and thus 

has not been withdrawn. 

Claim 13 . Dependent Claim 1 3 was amended in the prior response to correct an 
antecedent issue found by Applicant (nothing was specified). Applicant apologizes that 
the amendment toward overcoming the 1 12 rejection was omitted from the list of the 
claims amended per the 1 12 rejection. In particular, said means was recast to assure 
proper antecedent basis with parent Claim 1 , explicitly reciting " explicitly marking 
packets , in the sender" . Additionally, Claim 13 is currently amended to amend "a 
sender" to "the sender" thus assuring that it is the sender described in Claim 13 and in 
Claim 1 that is being referred to. If any further issue remains in this regard, it would be 
beneficial that the Applicant be apprised of specific details. 
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Therefore, the rejection of Claim 13 should be withdrawn. 

3. Discussion in "Response to Arguments" . 

Before proceeding to discuss the particulars of the shortcomings of the 
obviousness rejection, Applicant addresses issues which were brought forth in the 
"Response to Arguments" section of the Office Action which discussed the arguments 
put forth in the prior response, and in view of the interview discussed above. 

The Examiner's contentions regarding obviousness are based on equating 
sequence numbering and/or fragmentation control with the explicit back-to-back packet 
marking recited herein. In section 50 of the present action, discussing Claim 1, the 
Examiner contends that the combination comports with the recited claim as follows: 
"...packets are indicated as being sent back-to-back by initially unsetting the indication 
bit in the TCP header field, such that they are marked as back-to-back by default." 

The Examiner, however, never cites WHAT INDICATION BIT. It is further stated 
that "Furthermore, applicant argues that by contrast, NONE of the cited references are 
directed to control congestion in response to these packet trains. However, by 
definition, packet fragmentation means that the packets are not homogenous. 
Therefore, by not marking the packets, they are recognized as being homogenous." 
Here we see the argument posited which appears to connote a relationship between 
packet trains and some unspecified understanding of "homogeneous" as relating to the 
sequence. It seems it is being asserted that packets which are not marked are 
apparently part of different packet sequences (non-homogenous) - however, as will be 
discussed, this is not the definition of "back-to-back" within a packet sequence. The 
argument does not bear on the obviousness of the explicit back-to-back packet marking. 

Although the Office Action does not specify which bits were being referred to "in 
the TCP header", the interview cleared this up as being considered the packet 
sequence, and/or bits relating to fragmentation, although the Examining group did not 
elucidate any specific bits in this regard. 
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Sequence and Fragmentation Versus Explicit Back-to-Back Marking 

This section provides background information describing fundamental differences 
to aid the discussion and understanding between sequence numbering and 
fragmentation control in relation to the explicit back-to-back marking by the sender as 
recited in the present invention. 

Before proceeding to discuss fragmentation, the topic of packet sequence 
number is discussed, as the use of fragmentation can only be properly understood in 
the context of packet sequencing. 

Description of Sequence Numbering . 

In order to assure that packets are reassembled in the proper order at the 
destination, despite being received out of order, such as losing their order with respect 
to being subject to different delays and paths, a packet sequence number is relied upon. 
Consider the example of numbering packets as 0, 1 , 2, 3,4, . . .9; wherein at the 
destination it can be readily determined how to reorder the packets for use according to 
their sequence number. It will be noted, however, the sequence number provides 
NO information as to whether or not these packets were sent within the same 
packet train, or burst, only that they are sent within the same sequence, (definition of 
back-to-back is that they are in the same packet train with no inter-packet gap ("ipg") 
between respective packets) - discussed later on. 

A problem then arises with ordering the packets when a packet must be broken 
up (fragmented) as it traverses the network. It should be noted that not all portions of a 
network support the same MTU (maximum transport unit - packet core), wherein 
packets can be broken up "fragmented" without any knowledge of this fragmentation by 
the original sender. In considering an example of each incoming packet being split into 
two packets at some point along the transmission path, consider the reception of 
packets with sequence numbers 2, 1 , 2, 1 , 0, 0, 3, 4, 3, 4, .. .8, 8, 9, 1 0, 9, according to 
the previous packet sending example described above. How then does the receiver 
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discern how to assemble these packets? In addition, how does the receiver know when 
it can begin re-assembling a packet, unless it knows if any more fragments exist? How 
would the receiver know where to position the bits of each fragment in relation to the 
prior fragment? Accordingly, packet fragmentation is controlled using fragment fields 
within the TCP header to respond to these problems. 

Description of Fragmentation Control . 

Attached is a document entitled " What is a Packet Fragment " from the site 
www.tech.faq.com. "Fragmentation", as relating to the control of packet fragmentation 
across a network and, in particular, the flags and fragment offset fields in a packet 
header, is also a specific term of art which should not be confused with the ordinary use 
of the term "fragment", as meaning simply to divide something. 

As described above, fragments arise when a packet sent by a first network 
device (sender) with a first MTU size, must be broken up by a second, third or nth 
network device as that packet is communicated toward its final destination. In 
particular, fragmentation information is conveyed via a set of flags, and a fragment 
offset. Three flag bits are contained here in the Internet protocol: BitO - always set to 0; 
Bit1 - 0=you may fragment the packet, 1=you may not fragment the packet; Bit2 - 0=last 
fragment, 1 =more fragments coming. The fragment offset is a 1 3 bit offset value 
(typically octet value) describing where the fragment fits into the original datagram 
(packet) in terms of bytes divided by 8 (octets). It should be appreciated that 
"fragmentation" of this nature is not performed by the sender when it divides incoming 
data, or data stream, into a series of packets . Unfortunately, the original application 
speaks of fragmentation in some places in its non-art meaning of "to divide" when 
discussing the generation of the original packet; it was not considered that any 
confusion could arise with regard to the technical use of "fragmentation" as generated 
downstream within the network as the originally sent packets are 'repackaged' into 
fragments. The specification is amended herein to replace the word "fragment" with 
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"divide" as seen in paragraph [0009] toward removing any such source of confusion. 

It will be noted that the fragmentation and its field information is not generated by 
the first sender , but that this additional information is added to the header as the packet 
traverses the network and becomes fragmented out of necessity. It should also be 
noted that fragmentation has nothing to do with whether these packets were sent 
with an inter-packet gap by the original sender (ergo - fragmentation does not relate 
to the question of back-to-back sending of the packets in the original packet train) . 

We have clearly seen that neither Packet Sequence Number fields nor 
Fragmentation fields provide ANY indication of whether the packets were sent 
back-to-back, - - they only provide a specification of order for the packets and 
fragments of segments, respectively. 

Description of Back-to-Back Packet Sending . 

The term "back-to-back" in the context of the instant application is a particular 
term of art that is well known in the art, thus the original application did not provide a 
tutorial on the meaning of what constitutes "back-to-back" packets. Even in normal 
parlance it would be incorrect to consider that sequential packets within any stream of 
packets are of necessity "back-to-back", because when the back of one thing is against 
the back of another, there is nothing in-between - no gap. Analogously, the cars 
connected in a diesel powered train are coupled to one another - if a gap exists 
between the couplers of one car and the next, then the cars are not in the same train. 
Even the dictionary uses phrases like: " adjacent or contiguous ", " one following 
immediately after the other ", " unbroken seguence ", and " consecutive " (Webster's 
Encyclopedic Unabridged Dictionary ©1996). 

In the art, the term "back-to-back" is a term indicating that a group of packets, 
typically referred to within a burst or packet train, are sent directly " one after another in 
sequence" (as described in paragraph [0009] of the specification), and thus without any 
inter-packet delay . The lack of delay between back-to-back packets is described in 
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paragraph [0071] of the instant application: "For example, relying solely on such back- 
to-back packet estimates by the receiver is inherently inaccurate and error prone, 
because the sending unit 110 might delay packet transmissions for various reasons ." 
Consequently, the packets within a single burst are sent without any inter-packet 
delays, such as overhead, sending of other sequences, ACKS, and the like. 

It should also be noted that the packets in a packet train even when sent back- 
to-back, can be received with inter-packet gaps in response to receipt by a local 
network that is faster than the uplink. In considering this, it will be appreciated that no 
downstream receivers can accurately ascertain whether packets were originally sent 
"back-to-back" . 

It is also well known that different network systems have differing abilities to 
process packets "back-to-back"; that is to process a sequence of packets which arrive 
without any inter-packet gap between each packet of the given sequence. A typical 
parameter referring to this ability is "pace-size", such as from 1-256 packets, which 
specifies the capability of the system as per how many packets can be sent out from the 
system without an interpacket gap. [This is a system parameter, not to be confused 
with a packet or packet train bit - this is not contained in packet headers, and does not 
specify whether specific packets being sent back to back.] In view of this, we see that 
"back-to-back" is a defined characteristic of different systems. 

Accordingly, we see that indicating that packets are sent "back-to-back" is more 
than just indicating that the packets are within the same sequence of packets , because 
there are often delays between the sending of each packet within a sequence of 
packets. In fact a full ACK cycle can be performed between each packet within a 
sequence, even with a full handshake delay between packets, while the packets are still 
in the same sequence. In addition, we also see that "back-to-back" is not determined in 
relation to the order of packets within a sequence, or a datagram . 
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Advantages of "Back-to-Back" Packet Sending . 

The background of the invention (paragraphs [0009] and [0014]-[0022]) 
discusses the throughput advantages of sending packet trains and the difficulties which 
arise using conventional methods of bandwidth estimation in receiver-side TCP 
congestion control and controlling the length of packet trains. Packet trains can be sent 
without the ACK overhead for each of the packets, which is a clear advantage toward 
reduced overhead. Packets within a "train" are directly coupled to one another with no 
intervening gaps, just as the various boxcars, flatcars and reefers in a cargo train 
connect together and are pulled by the same locomotive. 

The object of the invention, as recited in the transitional last paragraph of the 
background is "for providing a robust and accurate form of bandwidth estimation for use 
in performing receiver-side TCP congestion control, and for controlling the length of 
packet trains." The bandwidth estimates in the present invention are enhanced by 
" explicitly marking each packet that is being sent back-to-back (alternatively inverse 
marking logic can be less preferably utilized) " (see paragraph [0027]), "wherein error- 
prone receiver side 'estimating' of back-to-back packets is unnecessary " (paragraph 
[0062]). The text goes on to describe two alternate means of performing the explicit 
marking of back-to-back packets. 

Distinction of Explicit Marking of "Back-to-Back" Packets within a Packet Train . 

It should be recognized from the above discussion that neither Sequence 
Number, nor Fragmentation Control fields specify whether the respective packets were 
originally sent with any inter-packet delay. Both of these sets of fields specify the order 
of packets and subpackets , while the flags field of fragmentation control bits can only 
indicate if the packets can be fragmented and if any more fragments are forthcoming. 
There is nothing in these fields which provide any indication of whether the 
packets are sent in a back-to-back manner. It is with the above discussion in mind 
that the specific claims of the instant application are discussed. 
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4. Rejection of Claims 1-8, 10-17, 22-32, and 36-39 under 35 U.S.C. 5 103(a) . 

Claims 1-8, 10-17, 22-32, and 36-39 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Yoshimura et al. (U.S. Patent No. 6,125,397), hereinafter 
'Yoshi', in view of Brown et al. (U.S. Patent No. 7,266,613) hereinafter 'Brown' and 
further in view of Samuels et al. (U.S. Appl. Publ. No. 2005/0005024 A1 ) hereinafter 
'Samuels. 

(a) Claim 1 . Independent Claim 1 is directed to a system for controlling 
network congestion. 

In support of the rejection, Examiner considers Yoshimura (Yoshi) as teaching a 
system for controlling network congestion, and Brown teaching the sending of packets 
" back-to-back'. It should be appreciated, before proceeding, that it is well known that 
packets can be sent "back-to-back" and thus without interpacket delay. It is also known 
that many systems have tried to control network congestion. However, the objects and 
operating principles of the present invention are directed as a means for explicitly 
marking at a sender which packets of a sequence are sent "back-to-back", and using 
that explicit information from the sender for controlling network congestion. These 
aspects of the instant application are clearly distinct from the teachings of the cited 
references. 

Examiner admits that Yoshi in view of Brown "does not teach explicitly indicating 
which packets are being sent back-to-back". Examiner asserts that "Sam teaches a 
system indicating packets based off of their status ([0146] & [0147]), in Sam's case the 
status indicated is packet fragmentation that implies the packets are being sent 
sequentially." Examiner goes on toward supporting why the combination of Sam 
(Samuels) with Yoshi and Brown would be obvious. 

However, a number of problems exist with support for the rejection. It should first 
be appreciated that the instant application operates according to different objects and 
operating principles than the cited references. 

Although packets are often sent sequentially, or even back-to-back within a 
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sequence of a conventional TCP systems, one of the problems being met in the present 
invention relates to controlling network congestion in response to packet trains (bursts) 
sent from sender to receiver. The claimed invention provides for controlling network 
congestion on the basis of "explicitly indicating which packets within the sequence of 
packets are being sent back-to-back' as recited in Claim 1 . The cited references do not 
provide any teachings for this aspect of the invention. 

The back-to-back aspect of the present invention which is recited in the claims is 
described in paragraph [0009] of the instant application: "A data object to be sent is 
divided into a sequence of packets. Typically the packets are sent sequentially based 
on their position in the original data object. When sequential packets are communicated 
one after another in sequence they are referred to as being "back-to-back" packets, 
since they are sent in a single burst and the sequence is not broken by the 
communication of other forms of packets, such as according to retransmitting in 
response to packet errors. If sufficient bandwidth exists larger numbers of packets 
should be sent back-to-back." By contrast, NONE of the cited references are directed to 
control congestion in response to explicit indications of which packets were sent within 
these packet trains of "back-to-back packets". 

The Yoshimura (Yoshi) reference describes conventional recovery-type 
congestion control as seen in its abstract: "A data transfer apparatus and method uses 
recovery-type congestion control and avoidance-type congestion control. A bandwidth 
determination unit determines requested bandwidth for a congestion avoidance-type 
data transfer in accordance with control information communicated between 
applications prior to the congestion avoidance-type data transfer." The Examiner 
indicates Yoshimura (Yoshi) doesn't teach packets being sent back-to-back. It should 
be recognized that Yoshimura (Yoshi) provides no control of the extent to which packets 
are sent back-to-back, or of marking packets sent back-to-back. 

The Brown reference describes "Fast Dynamic Measurement of Bandwidth in a 
TCP Network Environment' as found in the title of that reference. Examiner refers to 
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back-to-back packet sending in Col. 5, lines 23-30 and Col. 6, lines 31-40. 

In Col. 5, lines 23-30 of Brown a technique called "packet-pair" is referred to as 
follows: "With packet-pair, two identical packets are sent back-to-back. The server 
sends a pair of packets, one immediately after the other. Both packets are identical; 
thus they have the same size (PS). The bandwidth is determined by dividing the packet 
size by the time difference in reception of each packet." First, it is seen that the use of 
"packet-pairs" are used as a bandwidth measurement with two identical packets being 
used. These marker packets are identical and identifiable, thus the packet-pair does 
not comprise packets within a sequence of packets as recited in Applicant claims. In 
addition, since packet trains are admittedly known with strings of packets being sent 
"back-to-back", the Brown reference provides nothing of relevance. Brown does not 
teach any mechanism for a sender marking of which packets have been sent "back-to- 
back" with no delay between successive packets. 

In Col. 6, lines 31-40 of Brown, the "packet-pair" is expanded with multiple 
packets being sent and speed calculated for each. Again the discussion is about 
estimating bandwidth in response to speed determinations of the packets. The 
estimations are performed at the receiving end. Although Brown provides an estimation 
method, it is a method which lacks the accuracy of the explicit back-to-back packet 
marking recited in the present invention, and clearly does not comport with the 
teachings of the present invention. 

Brown provides no teaching relating to determining which packets are sent back- 
to-back, and more particularly of explicitly marking those packets as being sent back-to- 
back by the sender. 

Towards overcoming the deficiencies with these references, the Samuels (Sam) 
reference is combined with Yoshimura and Brown. The Samuels reference is a 
"Method of Determining Path Maximum Transmission Unit (PMTU), or path MTU, as 
recited in the title of the invention. Samuels discusses the use of a performance- 
enhancing proxy (PEP) (paragraph [0014]) with the object of the invention described in 
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paragraph [0027] of the Samuels reference, as: "Consequently, a new method of 
deploying PEPs is required to efficiently integrate them into a network. These PEPs 
must supply algorithms that remove the performance limitations inherent in TCP 
implementations." The Summary of the Samuels invention in paragraph [0028] 
describes the invention as: " A method of detecting the maximum transmission unit of a 
path between two performance enhancing proxies is disclosed ." The summary 
concludes by describing the mechanism by which the value of PMTU is altered: "Upon 
arrival, the downstream proxy determines if fragmentation of the packets has occurred. 
The downstream proxy notifies the upstream proxy of the determination. The upstream 
proxy uses the notification from the downstream proxy to retain, revert or alter the new 
estimated PMTU." (emphasis added) 

The cited paragraphs [0146] and [0147] within Samuels are consonant with the 
above in describing notification of the upstream PEP in response to detecting 
"fragmentation" . From the discussion earlier discussion of sequence number and 
fragmentation control, it will be recognized that this has no relationship to a sender 
explicitly marking packets as being sent "back-to-back": (1) no explicit marking, (2) not a 
sender based function, (3) determining split up of packets as they traverse network, no 
indication of whether delays in between packets wherein it does not relate to whether 
even fragments are received "back-to-back, and so forth. Paragraph [0146] states: "The 
receiving PEP observes the arrival of packets. If the receiver detects the arrival of a 
fragmented packet, then the receiver reports back to the sender that fragmentation is 
occurring, by marking the ACK packet that is generated for the received packet." 
(emphasis added) In view of the above it is clear that fragmentation is not related to 
disruptions in the back-to-back train of packets, but is in response to receipt of a packet 
fragment (an error, or the breakup of a packet traversing the path) instead of a whole 
packet. This is why there is no mechanism described for detecting the "fragments", 
because receivers are already configured to determine if received packets are whole 
and correct. This understanding is borne out in other parts of Samuels as follows. 
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In paragraph [01 12] Samuels describes the meaning of "fragmentation": "As 
described above, TCP performance is proportional to packet size. Thus increasing 
packet sizes improves performance unless it causes substantially increased packet loss 
rates or other nonlinear effects, like IP fragmentation . In general, wired media (such as 
copper or fiber optics) have extremely low bit-error rates, low enough that these can be 
ignored. For these media, it is advantageous for the packet size to be the maximum 
possible before fragmentation occurs (the maximum packet size is limited by the 
protocols of the underlying transmission media)." 

It can be recognized from the above that Samuels is not discussing anything 
relating to a sender explicitly marking packets which are sent back-to-back , but only of 
communicating the receipt of packet fragments by the receiver back to the sender to 
determine the maximum transmission unit (MTU) value to be used to size the packets. 
It will be readily appreciated that determining whether one has a partial packet is 
entirely different than detecting the extent to which intact packets are being received 
sequentially "back-to-back" as they were sent out without delays between these 
packets. 

More pointedly, as mentioned Samuels does not teach any "means for explicitly 
indicating which packets within said seguence of packets are being sent back-to-back '. 
Thus, combining Samuels with the other references still provides no teaching for 
aspects of the invention recited in the claim. 

Accordingly, as the Samuels reference in combination with the Yoshimura and 
Brown and what is known to one of ordinary skill in the art does not result in the 
invention as recited in Claim 1 , wherein a lack of support exists for the rejection of 
Claim 1. 

Furthermore, Applicant has amended Claim 1 to recite what is meant by "back- 
to-back" in the sequence of packets as: " means, within said device, for sending packets 
of a seguence in a back-to-back nature, wherein back-to-back packets are packets 
which are communicated, with no delay between the back of one packet and beginning 
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of the next packet one after another in a single burst within the sequence of packets." 
(underlining showing the most recent amendment). The amendment thus inculcates 
what is in the specification about "back-to-back" packet trains, toward eliminating any 
possible improper speculations thereto. 

Therefore, the above shows that the combination of references does not provide 
any teaching, suggestion, or motivation for that which is recited in the claims of the 
instant application and does not render the claims obvious. Applicant respectfully 
requests that the rejection of Claim 1 , and the claims which depend therefrom, be 
withdrawn. 

(b) Claim 14 . Independent Claim 14 is directed to a system for controlling 
network congestion. 

Support for the rejection follows that which was given in regard to Claim 1 
discussed above. 

As discussed in relation to Claim 1 , the elements of Claim 14 describe "marking 
packets , in a sender, to explicitly indicate if they are sent back-to-back'. Examiner 
admits that Yoshimura and Brown provide no such teachings, wherein the teaching of 
detecting "fragments" by Samuels is relied upon. 

However, as already discussed in relation to Claim 1 , Samuels does not explicitly 
mark any packets, prior to sending, with an indication of whether they are being sent 
back-to-back. In addition, the detection of fragmentation by Samuels has been shown 
to detect packet fragments which does not comport to indicating the extent to which 
packets are being sent back-to-back. 

Furthermore, Applicant has amended Claim 14 to recite "back-to-back" packet 
sending as: " sending packets of a sequence in a back-to-back nature in a single burst in 
which there is no delay between the back of one packet and the beginning of the next 
packet ' (underlining showing the most recent amendment). The amendment thus 
manifests the essence from the specification about what "back-to-back" packet trains 
are all about, toward eliminating improper speculations. 
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Accordingly, the combination of the cited references in view of what is known in 
the art does not provide teaching, suggestion, or motivation for the aspects of the 
invention as recited in Claim 14. Therefore, the Applicant respectfully requests that the 
rejection of Claim 14, and the claims that depend therefrom, be withdrawn. 

(c) Claim 26 . Independent Claim 26 is directed to a system for controlling 
network congestion. 

Support for the rejection follows that which was given in regard to Claims 1 and 
14 discussed in prior sections. 

In like manner to the traversal of the rejection of Claims 1 and 14, the elements 
of Claim 26 similarly describe "estimating network bandwidth in response to receipt of 
explicit indications of back-to-back packets or utilizing back-to-back packet estimations". 
Examiner admits that Yoshimura and Brown provide no such teachings, wherein the 
teachings of detecting "fragments" within Samuels are relied upon. 

However, as already discussed in relation to Claims 1 and 14, Samuels neither 
explicitly marks any packets, nor does it determine back-to-back packet estimations, as 
required by the claim. As discussed already, the detection of fragmentation by Samuels 
has been seen to detect packet fragments which do not relate to the extent to which 
packets are sent back-to-back, but only that the packet lengths are excessive. 

Furthermore, Claim 26 recites "sending packets of a sequence in a back-to-back 
nature in a single burst in which there is no delay between the back of one packet and 
the beginning of the next packet," and "explicit marking of packets which are sent back- 
to-back" for which no comparable teachings from the references are put forth in support 
of the rejection. It should be appreciated that none of the references provide any 
mechanism whatsoever for explicit marking of back-to-back packets for use in 
controlling the length of packet trains, but only for controlling the size of the packets 
being sent, which of course are two distinct forms of network control. 

Accordingly, the combination of the cited references in view of what is known in 
the art does not provide teachings, suggestion, or motivation for the aspects of the 
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invention as recited in Claim 26. Therefore, the Applicant respectfully requests that the 
rejection of Claim 26, and the claims that depend therefrom, be withdrawn. 

(d) Claim 27 . Independent Claim 27 is directed to a method of using 
bandwidth estimation to improve TCP congestion control. 

Support for the rejection follows that which was given in regard to Claims 1,14 
and 26 discussed in prior sections. 

The traversal of the rejection of Claim 27 follows similarly that of Claims 1,14 
and 26, as the elements of Claim 27 similarly describe "marking each packet, explicitly, 
that is being sent back-to-back, from a sender, to a receiver" and "estimating bandwidth 
in response to receiving packets from other senders which are explicitly marked as 
back-to-back packets". Examiner admits that Yoshimura and Brown provide no such 
teachings of bandwidth estimates, wherein the teachings of detecting "fragments" within 
Samuels are relied upon, which does not comport with the use of the explicitly marked 
back-to-back packets. 

As already discussed in relation to Claims 1,14 and 26, Samuels neither 
explicitly marks any packets, nor does it determine back-to-back packet estimations, as 
required by the claim. As discussed already, the detection of fragmentation by Samuels 
has been seen to detect packet fragments which bears no relationship to the extent to 
which packets are sent back-to-back, but only that the packet lengths are excessive for 
a given portion of the network being traversed. 

Furthermore, Claim 27 recites "wherein packets of a sequence are in a back-to- 
back nature when sent in a single burst in which there is no delay between the back of 
one packet and the beginning of the next packet" tor which no comparable teachings 
from the references are put forth in support of the rejection. It should be appreciated 
that none of the references provide any mechanism whatsoever for explicit marking of 
back-to-back packets for use in controlling the length of packet trains, but only for 
controlling the size of the packets being sent, which of course are two distinct forms of 
network control. 
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Accordingly, the combination of the cited references in view of what is known in 
the art does not provide teachings, suggestion, or motivation for the aspects of the 
invention as recited in Claim 27. Therefore, the Applicant respectfully requests that the 
rejection of Claim 27, and the claims that depend therefrom, be withdrawn. 

(e) Claims 2-13, 15-25, and 28-39 . Claims 2-13, 15-25, and 28-39 depend 
from claims whose patentability has been demonstrated, thus these dependent claims 
should be considered a fortiori allowable in view of their respective base claims. 

However, a number of these claims provide additional distinctions which have not 
been fully appreciated in the Office Action. The following claims are discussed by way 
of example. 

Claim 2 . In support of the rejection the sequence numbering described in 
paragraph [0148] of Samuels is relied upon in conjunction with the teachings of 
Yoshimura and Brown. 

Yoshimura and Brown clearly provide no teaching in relation to estimating the 

number of back-to-back packets and in particular using that information in combination 

with explicit back-to-back packet indications. However, the teachings of paragraph 

[0148] of Samuels also lacks such teaching and provides further support that the 

operating principles of Samuels does not relate to registering and controlling packet 

trains at all, but with reducing packet sizes in response to receipt of packet fragments. 

A portion of paragraph [0148] is as follows. 

"The active PMTU discovery algorithm operates by increasing the MTU of 
transmitted packets until a fragmentation indication is received, signaling that the 
PMTU has been exceeded. Because of the time lag between the sending of a 
larger packet and the reception of the ACK for it, as well as the use of cumulative 
ACKs, the PMTU discovery algorithm operates with imprecise information. In a 
preferred embodiment, the PMTU discovery algorithm increases the size of 
packets slowly, so as to reduce the uncertainty. The PMTU for a connection is 
increased by a few percent once for every RTT that elapses without a 
fragmentation indication . In a preferred embodiment, the seguence number of the 
first packet with an increased RTT is recorded . If that sequence number is 
ACKed without a fragmentation indication (either specifically or cumulatively), 
then the algorithm assumes that the PMTU for that packet is acceptable and 
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increases it, again recording the sequence number." (emphasis added) 

It is apparent that no "means for estimating the number of back-to-back packets 
received within a receiver from said sender and utilizing that information in conjunction 
with the explicit back-to-back packet information" is provided by the Samuels reference. 
RTT is the Round-Trip Time estimation for which each sequence of packets is 
timestamped. This mechanism can not be equated with an explicit marking that packets 
within a sequence of packets were sent back-to-back. 

Therefore, support is lacking for the rejection of dependent Claim 2, and the 
rejection should be withdrawn. 

Claim 4 . In support of the rejection it is asserted that the tracking of sequence 
numbers by Samuels comports to this aspect of the invention, while aspects of 
Yoshimura and Brown are not discussed. 

As has been discussed, neither Samuels or any of the other references teaches 
the use of an explicit back-to-back packet indication from a sender, indicating that 
packets were sent without any inter-packet delay. Thereby it makes no sense to assert 
that Samuels teaches a back-to-back estimate used "for checking the presence and 
validity of explicit back-to-back indications from the sender", as recited in Claim 4. 

Therefore, support is lacking for the rejection of dependent Claim 4, and the 
rejection should be withdrawn. 

Claim 8 . In support of the rejection, the modulating of header information by 
Samuels is asserted as recited in paragraphs [0147] and [0148]. 

Yoshimura and Brown are not brought forth in support as they clearly provide no 
teaching in relation to setting of header bits based on back-to-back status. 

However, the Samuels reference also lacks teaching which comports to this 
aspect of the invention. The cited paragraphs describe marking the ACK packet in the 
receiver in response to detecting packet fragments. 
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Claim 8 is directed at marking of packet header bits indicating back-to-back 
status prior to transmission of those packets . 

Therefore, as these have no correlation to that which is asserted for the cited 
references, then the rejection of Claim 8 should be withdrawn. 

Claim 13 . Similar to Claims 8 and 9, none of the cited references describe 
"marking packets according to whether or not they are being sent back-to-back'. 
Obviously, Yoshimura and Brown provide no such teachings. The cited Samuels 
reference detects the receipt of packet fragments and communicates this back to the 
sender to control MTU value, nothing is put forth for marking packets being sent in 
relation to whether they are being sent back-to-back. Again, we reiterate that packet 
sequence number and fragmentation fields do not provide any indication of whether 
packets are sent back-to-back and thus without any intervening delays between each 
packet sent by the sender. 

Therefore, these references provide no teaching, suggestion or motivation, either 
separately, or in combination with each other or what is known in the art, wherein they 
do not support the obviousness rejection. Applicant respectfully requests that the 
rejection of Claim 13 be withdrawn. 

Many of the remaining dependent claims suffer from shortcomings similar to 
those brought out above. In addition, all these dependent claims are progeny of claims 
whose patentability has been demonstrated wherein they should be considered a fortiori 
allowable. 

5. Rejection of Claims 9, 18-21, and 33-35 under 35 U.S.C. § 103(a) . 

Claims 9, 18-21, and 33-35 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Yoshi, Brown and Samuels as applied to Claims 1,14, and 27 above, 
and further in view of Huang et al. (U.S. Appl. Publ. No. 2003/0103453 A1 ) hereinafter 
Huang. 
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Claims 9, 18-21, and 33-35 depend from claims whose patentability has been 
demonstrated, thus these dependent claims should be considered a fortiori allowable in 
view of their respective base claims. 

However, as each of these claims provide additional distinctions which have not 
been fully appreciated in the Office Action, they are discussed in the following. 

Claim 9 . Similar to Claim 8 discussed previously, Claim 9 recites a mechanism 
using modulation of the MSS for explicitly indicating back-to-back status of a packet 
prior to its transmission. Yoshimura and Brown clearly provide no teachings of explicit 
back-to-back packet indications. In addition, it has been shown that the detection of 
packet fragments within a receiver by the Samuels reference, also does not comport to 
indicating back-to-back status prior to transmission. 

The rejection asserts that Samuels "does not disclose modulating the setting of 
the maximum segment size (MSS) for indicating back-to-back status of packets being 
transmitted'. In putting forth the combination with Huang it is asserted that "Huang 
teaches modulating the setting of the maximum segment size (MSS) for indicating back- 
to-back status of packets being transmitted [0068]." 

However, Applicant finds no support of this assertion in paragraph [0068] of 
Huang, nor can Applicant find support anywhere in the Huang reference regarding 
explicitly indicating back-to-back packets being transmitted, such as recited within the 
base claims of the instant application. 

Instead the Huang reference is directed to a time-division queue rate control 

scheme as seen in the Abstract of that invention, a portion of which reads as follows. 

"The TDQ-RCS according to the present invention can rapidly determine 
departure time of an arrival packet, add the arrival packet into the time division 
queue to which it belongs according to the departure time, and then output the 
packet on schedule." 

It will be seen that the above discusses registering departure time and not 
whether packets are sent back-to-back - thus by definition it is not an explicit reference - 
as the nature of the packets can only be inferred from the timing based on the receiving 
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end trying to guess at parameters such as speed, original packet sizing, and so forth 

from the original sender prior to changes which arise during communication, such as 

fragmentation of the packets within the packet sequence. Although no discussion was 

found in Huang for using these timestamps to determine the back-to-back relationship 

of packets, the background of the instant application in paragraph [0020]-[0021] 

discusses shortcomings of timestamp evaluation approaches which attempt to do so. 

In any case the Huang reference can not be said to provide the explicit marking 

of back-to-back packets being transmitted. One can see from paragraph [0068] that 

Huang partitions upstream and downstream traffic. 

"According to the present invention, a packet transmitted by the sender in 
the low rate direction will be partitioned into a series of smaller packets, if the 
payload size of the packet is larger than the legal rate predetermined for said 
traffic stream based on said QoS information. To achieve such partition, an 
optional header, Maximum Segment Size (MSS), of the TCP is employed in the 
present invention. The MSS is to set the largest payload size of the TCP traffic 
stream. " 

In relation to the above it will be seen that the Huang reference, considered 
either separately, or in combination with the other cited references and what is known in 
the art, could not provide proper support for an obviousness rejection of these 
dependent claims. 

Therefore, the rejection of Claim 9 should be withdrawn. 

Claim 18 . Claim 18 contains a recitation of using the changes in MSS to 
explicitly mark back-to-back packets being sent in the manner of Claim 9 above, but 
directed to base Claim 14. 

Therefore, the rejection of Claim 18 should be withdrawn. 

Claim 19 . Dependent Claim 19 is rejected on the basis of changing packet sizes 
to "improve the data for corresponding to available bandwidth". However, this 
characterization misses critical distinctions brought out in Claim 19 and its parent claim. 
In particular modulation of packet size is used as recited in Claim 19 as the explicit 
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indication that packets are being sent back-to-back. The cited references change 
packet length to accomplish direct objectives in response to fragmentation (Samuels) or 
bidirectional packet flow (Huang), yet there is no support given from these references 
that of modulating the MSS based on each packet being back-to-back with another 
packet prior to sending. Thus, in the claims of the instant application packet size was 
not changed as the object, or goal, but as an indication, or flag, which is used for 
allowing the length of packet trains to be increased. 

Therefore, the rejection of Claim 19 should be withdrawn. 

Claims 20-21 . Claims 20-21 contain further definitions of how the MSS is 
modulated as an explicit indicator of a packet that is sent back-to-back, and thus these 
claims are not obvious for the same and additional reasons as given in regard to 
Claim 19. 

Therefore, the rejection of Claims 20-21 should be withdrawn. 

Claims 33-35 . Claims 33-35 depend from independent Claim 27, and recite 
modulation of the MSS as an explicit indicator of a packet that is sent back-to-back, in a 
manner as recited in dependent Claim 18, which depended from independent Claim 14. 
For those same reasons, Claims 33-35 are not obviated by the teachings of Huang, in 
combination with Samuels, Brown, Yoshimura, and what is known in the art. 

Therefore, the rejection of Claims 33-35 should be withdrawn. 

Therefore, each of the above dependent claims should be considered a fortiori 
allowable in view of dependence from a base claim shown to be non-obvious, while 
each dependent claim provides further grounds for non-obviousness in relation to all the 
cited references, including Huang, and what is known in the art. 

6. Amendment of Specification . 

Paragraphs [0013], [0015], and [0059] of the specification have been amended to 
reduce any confusion between the term of art "fragment" and the non-art term 
"fragments" with regard to simply dividing an input. 
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Support for "dividing" the packets is seen in paragraph [0009]. The word 
fragment here could be easily confused with the process of dividing packets after they 
are sent by the sender during routing through network segments, wherein it has been 
appropriately changed in view of the context. 

7. Amendments to Claims 1 . 13-14. and 26-27. 

Claims 1, 14, and 26-27 . The independent claims within the instant application 
have been amended to recite with greater particularity what is meant by "back-to-back" 
packets, wherein the explicit marking of "back-to-back" packets can be better 
understood. 

The claims recite the "back-to-back nature" of the packet train, support for which 
is found in paragraphs [0026], [0043]-[0044] and so forth. Additionally, the claims spell 
out that back-to-back packets are communicated with "no delay" between the back of 
one packet and the beginning of the next packets, support for which is found in the 
specification at paragraphs [0021], [0071] and so forth. 

In particular the specific claims were changed as follows. 

Claim 1 was amended as " means, within said device, for sending packets of a 
sequence in a back-to-back nature, wherein back-to-back packets are packets which 
are communicated, with no delay between the back of one packet and beginning of the 
next packet, one after another in a single burst within the sequence of packets." 

Claim 14 was amended to include: " sending packets of a sequence in a back-to- 
back nature in a single burst in which there is no delay between the back of one packet 
and the beginning of the next packet. " 

Claim 26 was amended to include: " sending packets of a sequence in a back-to- 
back nature in a single burst in which there is no delay between the back of one packet 
and the beginning of the next packet and " explicit marking of packets which are sent 
back-to-back " 
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Claim 27 was amended to include: " wherein packets of a sequence are in a 
back-to-back nature when sent in a single burst in which there is no delay between the 
back of one packet and the beginning of the next packet . " 

Claim 13 . Dependent Claim 13 has been amended to change "a sender" to read 
"the sender" to provide a proper antecedent. Additionally, the explicit marking phrase is 
amended to recite the lack of delay between packets as "explicitly marking packets, in 
the sender, according to whether or not they are being sent back-to-back without delays 
between successive packets ", support for which was given in relation to Claim 1 . 

8. Amendments Made Without Prejudice or Estoppel. 

Notwithstanding the amendments made and accompanying traversing remarks 
provided above, Applicant has made these amendments in order to expedite allowance 
of the currently pending subject matter. However, Applicant does not acquiesce in the 
original ground for rejection with respect to the original form of these claims. These 
amendments have been made without any prejudice, waiver, or estoppel, and without 
forfeiture or dedication to the public, with respect to the original subject matter of the 
claims as originally filed or in their form immediately preceding these amendments. 
Applicant reserves the right to pursue the original scope of these claims in the future, 
such as through continuation practice, for example. 

9. Request for Continued Examination (RCE). 

An appropriate fee is enclosed for a RCE (Request for Continued Examination) 
of this application (See 37 CFR 1.114). 
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10. Conclusion . 

Based on the foregoing, Applicant respectfully requests that the various grounds 
for rejection in the Office Action be reconsidered and withdrawn with respect to the 
presently amended form of the claims, and that a Notice of Allowance be issued for the 
present application to pass to issuance. 

In the event any further matters remain at issue with respect to the present 
application, Applicant respectfully requests that the Examiner please contact the 
undersigned below at the telephone number indicated in order to discuss such matter 
prior to the next action on the merits of this application. 

Date: August 28. 2008 Respectfully submitted, 




John P. O'Banion, Reg. No. 33,201 
M. Robyn Carrillo, Reg. No. 47,474 
Rodger H. Rast, Reg. No. 45,853 
O'BANION & RITCHEY LLP 
400 Capitol Mall, Suite 1550 
Sacramento, CA 95814 
(916)498-1010 



Attachment: Paper Entitled - "What is a Packet Fragment' 
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Excerpt from www.tech-faq.com (search for fragmentation) 

What is packet fragmentation? 

Every packet-based network has an MTU" (Maximum Transmission Unit) size. The MTU is the 
size of the largest packet which that network can transmit. 



Packets larger than the allowable MTU must be divided into multiple smaller packets, or 
fragments, to enable them to traverse the network. 

; Network Standard MTU 

Ejheriiel 1500 
Token Ring 4096 

Packet Headers 

Every IP packet has an IP ( Internet Protocol) header which stores information about the packet, 
including: 



• Version 
. IHL 

• Type of Service 

• Total Length 

• Identification 

• Flags 

• Fragment Offset 

• Time to Live 

• Protocol 

• Header Checksum 

• Source Address 

• Destination Address 

• Options 

Note: For more information on the IP header, see RFC 791 - Internet Protocol . 
Three of these fields are involved in packet fragmentation. 
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• Identification 

• Flags 

• Fragment Offset 
Identification: 16 bits 

An identifying value assigned by the sender to aid in assembling the fragments of a datagram. 
Flags: 3 bits 
Various Control Flags. 

Bit 0: reserved, must be zero 

Bit 1 : (DF) 0 = May Fragment, 1 = Don't Fragment. 

Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 

0 12 



I I D | M | 
I 0 | F | F | 
+ + + + 

Fragment Offset: 13 bits 

This field indicates where in the datagram this fragment belongs. 

The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. 

Much like the IP header, the TCP (Transmission Control Protocol) header stores information 
about the packet: 

• Source Port 

• Destination Port 

• Sequence Number 

• Acknowledgement Number 
. Data Offset 

• Flags 

• Window 

• Checksum 

• Urgent Pointer 

• Options 

• Padding 

Note: For more information on the TCP header, see RFC 793 - Transmission Control Protocol . 
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A Packet Fragmentation Example 

If a 2,366 byte packet enters an Ethernet network with a default MTU size, it must be fragmented 
into two packets. 

The first packet will: 

• Be 1 ,500 bytes in length. 20 bytes will be the IP header, 24 bytes will be the TCP 
header, and 1,456 bytes will be data. 

• Have the DF bit equal to 0 to mean "May Fragment" and the MF bit equal to 1 to 
mean "More Fragments." 

• Have a Fragmentation Offset of 0. 

The second packet will: 

• Be 91 0 bytes in length. 20 bytes will be the IP header, 24 bytes will be the TCP 
header, and 866 bytes will be data. 

• Have the DF bit equal to 0 to mean "May Fragment" and the MF bit equal to 0 to 
mean "Last Fragment." 

• Have a Fragmentation Offset of 182 (Note: 182 is 1456 divided by 8). 
The Packet Fragmentation Attack 

Packet fragmentation can be utilized to get around blocking rules on some firewalls. 

This is done by cheating with the value of the Fragment Offset. The trick is to set the value of the 
Fragment Offset on the second packet so low that instead of appending the second packet to the 
first packet, it actually overwrites the data and part of the TCP header of the first packet. 

Let's say you want to "telnet" into a network where TCP port 23 is blocked by a packet filtering 
firewall . However, SMTP port 25 is allowed into that network. 

What you would do is to send two packets: 

The first packet would: 

• Have a Fragmentation Offset of 0. 

• Have the DF bit equal to 0 to mean "May Fragment" and the MF bit equal to 1 to 
mean "More Fragments." 

• Have a Destination Port in the TCP header of 25. TCP port 25 is allowed, so the 
firewall would allow that packet to enter the network. 

The second packet would: 

• Have a Fragmentation Offset of 1 . This means that the second packet would 
actually overwrite everything but the first 8 bits of the first packet. 
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• Have the DF bit equal to 0 to mean "May Fragment" and the MF bit equal to 0 to 
mean "Last Fragment." 

• Have a Destination Port in the TCP header of 23. This would normally be 
blocked, but will not be in this case! 

The packet filtering firewall will see that the Fragment Offset is greater than zero on the second 
packet. From this data, it will deduce that the second packet is a fragment of another packet and 
it will not check the second packet against the rule set. 

When the two packets arrive at the target host, they will be reassembled. The second packet will 
overwrite most of the first packet and the contents of the combined packet will go to port 23. 
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